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(54) A switched network architecture for ip multicast and integrated services 



(57) A method and a network architecture for map- 
ping Internetworking Protocol (IP) multicast and Inte- 
grated Services (i.e. differing levels of quality of service) 
over asynchronous transfer mode (ATM) networks, 
based upon multicast switches, allowing IP/resource 
reservation protocol (RSVP) applications running on 



ATM hosts to seamlessly participate in Internet-wide 
multicast sessions. The method and architecture 
employ ATM capabilities to support features such as 
receiver heterogeneity, shortcut routing and scalability. 
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Description 

Background of the Invention: 

[0001] The present invention relates to a method and s 
a network architecture for mapping Internetworking Pro- 
tocol (IP) multicast and Integrated Services (i.e. differ- 
ing levels of quality of service) over an Asynchronous 
Transfer Mode (ATM) network. The method and archi- 
tecture, which are based upon multicast switches, allow to 
IP/Resource Reservation Protocol (RSVP) applications 
running on ATM hosts to seamlessly participate in Inter- 
net-wide multicast sessions. The method and architec- 
ture make good use of ATM capabilities to support 
features such as receiver heteroganeity, shortcut rout- is 
ing and scalability. 

Description of the Related Art 

[0002] The current Internet services, including IP mul- 20 
ticast, are based on best effort delivery of datagrams as 
the sole underlying mechanism. The best effort delivery 
mechanism however, is not suitable for transporting 
media streams such as audio and video over the Inter- 
net, since applications using such streams often require 25 
data delivery with delay and bandwidth guarantees for a 
successful replay of media streams at the receiving 
.end. Furthermore, Internet traffic continues to grow 
faster than the speed at which additional capacity is 
being added to the Internet infrastructure. This means 30 
that data traffic traversing the Internet is subject to 
unpredictable delays and possibly packet loss due to 
the increased load on Internet routers. 
[0003] While traditional Internet applications such as 
email, file transfer, remote login etc., based on transmis- 35 
sion control protocol (TCP), can adapt their network 
usage to the prevailing conditions, emerging multimedia 
applications, such as video on demand and those 
based on streaming video, are less tolerant to changes 
in traffic parameters such as end-to-end delay and jitter. 40 
The only way to support those multimedia applications 
(other than over engineering the Internet capacity) is to 
provide multiple service classes and a capability of 
reserving resources in the Internet. 
[0004] As a result of the efforts of the Internet Engi- 45 
neering Task Force (IETF) (See, e.g., WroclawsW, spec- 
ification of the Controlled-Load Network Element 
Service, Network Working Group, Request for Com- 
ments: 2211, Category: Standards Track, September, 
1997; and Shenker et al., Specification of Guaranteed so 
Quality of Service, Network Working Group, Request for 
Comments: 2212, Category: Standards Track, Septem- 
ber, 1997), support for Quality of Service (QoS) based 
service classes, known as Integrated Services, is 
expected to become available in the Internet in the near ss 
future. In addition, Resource Reservation Protocol 
(RSVP) is also being standardized by the IETF as an 
internetworking protocol for resource reservation that 



will be used by applications in the multi-service Internet. 
See, R. Braden, etal.. "Resource Reservation Protocol 
(RSVP) - Version 1 Functional Specification" Internet 
Engineering Task Force, Network Working Group, 
Request for Comments: 2205, Category: Standards 
Track, September, 1997. 

[0005] Asynchronous Transfer Mode (ATM) has been 
developed as an integrated link layer and network layer 
solution for providing QoS based services in local and 
wide area networks. Although the ATM technology sup- 
ports its own version of QoS based services, it is 
unlikely that ATM networks will completely replace the 
existing IP based Internet infrastructure in the foreseea- 
ble future. Therefore, at least in the initial stages of ATM 
deployment, hosts connected to ATM networks will con- 
tinue to run IP and RSVP applications in order to com- 
municate with other hosts, most of which may still be 
connected to legacy networks, such as Ethernet. 
[0006] Since the ATM technology readily provides the 
QoS support needed for IP Integrated Services, the 
problem of mapping these services over an ATM net- 
work appears to be simple. However, such a mapping is 
quite difficult due to the following reasons: 

(1) Since IP is the network layer protocol of choice 
for use with RSVP, all the network technologies 
ranging from Ethernet to Token Ring to ATM will be 
treated as link layer technologies by RSVP/IR Such 
an approach does not give rise to any conflicts with 
the use of conventional network technologies such 
as Ethernet, but with ATM networks this approach 
has an inherent problem in that it fails to make use 
of the network layer capabilities (addressing and 
routing) of ATM; 

(2) IP multicasting, which is at the core of Integrated 
Services and RSVP, is being deployed widely in the 
existing IP networks. On the other hand, support for 
efficient multicasting in ATM is still inadequate. 
Point-to-multipoint virtual circuits (VCs). although 
supported in ATM, suffer from scalability problems; 
and 

(3) Some of the RSVP features, namely receiver 
heterogeneity and dynamic QoS, do not have 
equivalent mechanisms in ATM. 

[0007] One proposal to deal with the provision of IP 
Integrated Services over ATM is the Cell switch Router 
(CSR) from Toshiba. See, Katsube, et al., "Toshiba's 
Router Architecture Extensions for ATM: Overview," 
Network Working Group, Request for Comments: 2098, 
category: Informational, February, 1997. A CSR is a tra- 
ditional IP router attached to an ATM switch and is capa- 
ble of "concatenating" incoming and outgoing VCs to 
provide shortcut paths through routers in an ATM cloud. 
Individual intra-logical IP subnet (LIS) VCs (host to 
router or router to router) are established using ATM sig- 
naling. Such VCs may be point to point for unicast, or 
point to multipoint for multicast. Different VCs may be 
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established for different Hows" between the same set of 
endpoints to allow for a different QoS for each flow, e.g. 
using RSVR The problem is that CSRs use IP based 
protocols to route data traffic and thus limit the use of 
ATM protocols to intra- LIS routing. Some of the disad- 5 
vantages of this approach are: 

(1) A true shortcut path between two endpoints may 
not go through a router (CSR) which is given as the 
next hop by IP routing. This is because IP routing 
needs to send all data crossing subnet boundaries 
through a router (CSR); 

(2) Wide area addressing and routing capabilities of 
ATM are not utilized properly by this approach since 
ATM is used only as a link layer; and 

(3) Currently there is no proposal to handle hetero- 
geneous QoS receivers in a multicast session with 
CSRs. 

[0008] Two other recent proposals dealing with IP 
switching, are IPSILON and IPSOFACTO. See, A. Ach- 
arya, et al. "IP switching over fast ATM cell transport 
(IPSOFACTO), Proc. Of IEEE Globecom '97, 1997; and 
P. Newman, et al., Transmission of Flow Labeled Ipv4 
on ATM Data Links Ipsilon Version 1.0", Network Work- 
ing Group, Request for Comments 1954, Category: 
Informational, May, 1996. IP switching "identifies" long 
lived IP flows passing through a switch router (IP switch) 
and places such flows on a fast switched path so that 
subsequent data packets on these flows do not incur 
reassembly, routing and segmentation delays at the 
router. IPSILON uses a heuristic based on the number 
of packets with the same source and destination 
addresses to identify a long lived flow. IPSOFACTO 
relies on the control packets of higher layer protocols, 
e.g. SYN packets in TCP, to identify long lived flows. 
Once a long lived flow is identified, it is assigned a new 
Virtual Circuit Indicator/Virtual Path Indicator (VCI/VPI) 
by the IP switch. At the same time, an association 
between the incoming VCI/VPI and outgoing VCI/VPI is 
established in the switching fabric so that subsequent 
data packets are forwarded without any intervention by 
the routing software. IPSILON relies on a proprietary 
Protocol for assigning VCI/VPI to IP flows between two 
IP switches. IPSOFACTO uses a technique based on 
partitioning of VCI/VPI space and chooses an unused 
VCI/VPI from this space for forwarding a flow through 
each IP switch. The only difference between the two IP 
switching techniques and the CSR technique described 
earlier is the way shortcut VCs are established by the 
switch/router. Apart from this difference, the two IP 
switching techniques and CSR rely on IP routing soft- 
ware to make routing decisions. As such, all the draw- 
backs listed earlier for CSR, apply equally well to the 
two IP switching techniques. 

[0009] Additionally, the IP over Non-broadcast Multi- 
ple Access (NBMA) networks (ION) working group of 
the IETF has developed a proposal for IP multicast over 



ATM which is based on Multicast Address Resolution 
Servers (MARSs) See Q.J. Armitage, Support for multi- 
cast over UNI 3.0/3.1 based ATM networks, Network 
Working Group, Category: Standards Track, Request 
for Comments 2022, November 1996. An enhancement 
to the basic MARS approach is the concept of a Multi- 
cast Server (MCS). See R. Talpade, et al., Multicast 
server architectures for MARS-based ATM multicasting, 
Network Working Group, Category: Informational, 
Request for Comments 2149, May 1997, which helps 
aggregate traffic from multiple sanders to a given multi- 
cast group. If one active MARS per LIS is used in an 
ATM cloud, point-to-multipoint VCs for multicast distri- 
bution are confined to LIS boundaries and inter LIS mul- 
ticast forwarding is accomplished by multicast routers. 
Shortcut routing of multicast traffic is not possible in 
such a case. On the other hand, if one MARS is used for 
the whole ATM cloud, point-to-multipoint VCs may span 
the whole ATM cloud which causes scaling problems if 
the number of ATM hosts in the ATM cloud is large. See 
GJ. Armitage, VENUS-Very Extensive Non-Unicast 
Service, Internet Engineering Task Force, Network 
Working Group, Request for Comments: 2191, Cate- 
gory: Informational, September, 1997. As a compari- 
son, the inventive network architecture, discussed in 
more detail below, is scalable since it uses separate 
VCs for intra and inter LIS multicast traffic, while allow- 
ing shortcut routing by concatenating these VCs at mul- 
ticast switches (MSWs). Another problem with the 
MARS/MCS approach is the inability of multicast send- 
ers to communicate QoS retirements to the MCS for the 
multioast traffic originating from the sender. However, in 
the present invention, since the MSW is the termination 
point for RSVP messages within an LIS, using it as an 
MCS allows the use of QoS VCs from the sender to the 
MSW/MCS. 

[0010] In yet another proposal, the Integrated Serv- 
ices over Specific Link Layers (ISSLL) working group of 
the IETF deals with the mapping of Integrated Services 
over ATM, treating it as a link layer technology. The cur- 
rent proposals in the ISSLL working group for mapping 
RSVP over ATM (see Crawley et al., A Framework for 
Integrated Services and RSVP over ATM, Internet Engi- 
neering Task Force, Internet Draft, <draft-ietf-issll-atm- 
framework-00.txt), July 24, 1997; and Berger, RSVP 
over ATM Implementation Requirements, Internet Draft, 
(draft-ietf-issll-atm-imp-req-00.txt), July 11. 1997). rec- 
ommend supporting a modified homogeneous model as 
an approximation to full receiver heterogeneity. In the 
proposed scheme, all QoS receivers are served by a 
single QoS VC, and best effort receivers are served by 
a separate best effort VC if they cannot be served by the 
QoS VC. The ISSLL proposals contain no clear discus- 
sion of multicasting across LISs (i.e., inter-LIS multi- 
casting). Although it allows the existence of a MARS 
and also some shortcut routing, it is not clear if a single 
point-to-multipoint VC per gender (or MCS) will span the 
ATM cloud connecting senders directly with receivers or 
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if IP routers will be called in to route multicast traffic 
between LISs. A part of the confusion stems from the 
fact that the ISSLL group by definition is constrained to 
treat ATM as a link layer technology, although ATM can 
be utilized to perform routing functions as well. Shortcut 
routing, which allows multicast traffic to bypass multi- 
cast routers and requires a broader outlook, clearly falls 
outside the purview of the ISSLL working group. 
[0011] Another recent proposal in the ISSLL group 
uses Next Hop Resolution Protocol (NHRP) to establish 
shortcut paths with QoS between two hosts/routers 
connected to an ATM network. See, Guerin et al., Sup- 
port of shortcuts for RSVP Flows Over ATM, Internet 
Engineering Task Force, Internet Draft (draft-guerin- 
issli-rsvp-shortcut-OO.txt). See also, Luciani et al., 
NBMA Next Hop Resolution Protocol (NHRP), Routing 
Over Large Clouds Working Group, Internet Draft 
< draft-ietf-rolc-nhrp-1 2.txt ) . Although this proposal 
does establish a shortcut path between the two end- 
points using ATM signaling, it does not handle the multi- 
cast case since NHRP cannot resolve multicast IP 
addresses to ATM addresses. 

[0012] Another proposal discusses different alterna- 
tives for establishing RSVP reservations for unicast and 
multicast flows. Various methods are described to 
achieve both root-initiated (root of the multicast tree) 
and leaf-initiated (a leaf could be a multicast receiver or 
.an egress router) shortcut paths through an ATM net- 
work. Birman, et al. "Provisioning of RSVP-based serv- 
ices over a large ATM network," IBM Research Report 
(Computer Science) #RC 20250, October, 1995. How- 
ever, all the methods described for establishing shortcut 
paths through the ATM network require modifications to 
RSVP processing at the rooters. Furthermore, direct 
shortcuts from sanders or ingress routers to receivers or 
egress routers do not scale if the number of multicast 
receivers is large. The aforementioned methods are 
described in a very general form and no concrete imple- 
mentation details are mentioned. Additionally, there is 
no mention of how heterogeneous receivers can be 
supported. By contrast the present invention, described 
below with reference to a preferred embodiment, imple- 
ments a scalable network architecture based on multi- 
cast switches which provides shortcut paths that are 
incrementally established and concatenated for scala- 
bility. Support is also provided for heterogeneous 
receivers. No modifications are needed in RSVP 
processing. The aspects related to ATM and shortcut 
routing are handled only within multicast routing. 
[001 3] Another recent proposal describes the design 
and implementation of a switch router that is capable of 
providing quality of service using RSVP. E. Basturk et 
al., Design and implementation of QoS capable switch- 
router, Proc. of the Int'l Conference on Computer Com- 
munications and Networks (IC3N). Sept. 1997. Detailed 
design and implementation of the hardware in the 
switch router is presented. The switch router described 
can be thought of as a CSR from Toshiba (described 



earlier), augmented with QoS capabilities using RSVP. 
The proposed Switch-Router uses IP routing protocols 
and RSVP to establish unicast and multicast switched 
paths in an ATM network. The ATM network, as in 

5 Toshiba's CSR, is treated as a layer 2 network so that 
forwarding across subnet boundaries takes place via a 
router (switch router in this case). However, the switch 
router architecture is described in isolation without any 
mention of how such switch routers will work together to 

io provide a scalable mapping of IP multicast and RSVP 
over sizable ATM networks with features such as 
receiver heterogeneity. Therefore, most of the limita- 
tions arising out of the use of IP based protocols in ATM 
networks as described earlier in the discussion on 

is Toshiba's CSR, apply to this switch router as well. In 
particular, the issues related to VC management for an 
ATM network consisting of a number of LISs and using 
the addressing and routing capabilities of ATM are not 
addressed in this paper. Furthermore, extensions to 

20 RSVP messages are required to carry VC information 
from one switch router to the other. 
[0014] By contrast, the present invention describes a 
scalable network architecture based on multicast 
switches, which supports features such as shortcut 

25 paths and receiver heterogeneity. Details are provided 
below to show how multicast switches can operate 
together to provide IP multicast and Integrated Services 
in an ATM network, exploiting the routing and address- 
ing capabilities of ATM as much as possible. Further- 

30 more, no modifications are needed in RSVP messages 
in the inventive architecture. 

Summary of the Invention: 

35 [001 5] The present invention provides a solution to the 
problem of supporting IP multicast and Integrated Serv- 
ices over ATM. The invention sets forth a method and 
network architecture, based on multicast switches for 
mapping IP multicast and Integrated Services over ATM 

40 networks. A multicast switch (MSW) is an ATM switch 
that can also perform the functions of an IP multicast 
router, including that of terminating RSVP messages. 
The primary problem addressed by the present inven- 
tion is of mapping the protocol mechanisms (IP multi- 

45 casting protocols and RSVP) that deliver IP multicast 
and Integrated Services to suitable mechanisms pro- 
vided by ATM networks. 

[0016] The present invention, in providing a solution 
for mapping IP multicast and Integrated Services over 
so ATM, also provides a means for addressing the follow- 
ing objectives. 

[001 7] The first objective is to allow for receiver heter- 
ogeneity. RSVP allows different receivers in a multicast 
session to reserve resources with different QoS param- 
55 eters. rt is also possible that some receivers do not 
reserve any resources, but instead prefer to receive 
data with a best effort delivery mechanism. All such 
receivers must be supported by an RSVP over ATM 
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mapping. Since a point-to-multipoint VC in ATM cannot 
have different QoS parameters associated with its differ- 
ent branches, supporting receiver heterogeneity may 
require multiple VCs with different QoS parameters. 
[001 8] The second objective is to provide for shortcut 5 
routing. Shortcut routing for unicast traffic in an ATM 
cloud helps eliminate intermediate routing steps by 
using the routing and addressing capabilities of ATM in 
case two communicating hosts are connected to the 
same ATM network. Using a mechanism like NHRP, a w 
sender can find out the ATM address of the receiving 
host and establish a direct VC to it. Extending shortcut 
routing to multicast data traffic causes a variety of prob- 
r lems, however. First, using a shortcut point-to-multipoint 

VC for a multicast session in an ATM cloud will burden is 
/ the sender with managing a VC that can potentially 
span multiple LISs and have a large number of recipi- 
ents. Second, shortcut routing for multicast will allow 
data traffic to bypass multicast routers. This means that 
RSVP control messages (PATH and RESV) may follow 20 
a path that is different from the data path, giving rise to 
inconsistencies between the path characteristics com- 
puted by RSVP control messages and those actually 
\ encountered by the data traffic. A mapping must there- 
\ fore clearly specify the manner of support for shortcut 25 
routing for multicast traffic. 

[0019] The third objective is to provide adequate VC 
management A mapping should specify how VCs are 
established for multicast data traffic and RSVP control 
traffic. This involves identification of the end points so 
where a data or control VC terminates. This also 
involves delegation of VC management duties to send- 
ers and/or routers to handle changes in group meter- 
ship. If a mapping supports direct point-to-multipoint 
VCs between a sender and all the receivers in an ATM 35 
cloud, the sender needs to manage the VC endpoints. 
When new receivers join the multicast session, they 
have to be added as leaf nodes to the point-to-multipoint 
VC. On the other hand, when existing receivers leave 
the multicast session, they have to be removed from the 40 
point-to-multipoint VC. 

[0020] The fourth objective is to allow for dynamic 
QoS. RSVP allows multicast receivers to change their 
resource reservations at any time. Currently, User Net- 
work Interface (UNI) and Private Network Node Inter- 45 
face (PNNI) standards of the ATM Forum do not allow 
changing QoS parameters for an existing VC. 
[0021 ] A fifth objective is to provide scalability. A map- 
ping should be scalable to a large number of receivers 
and possibly a sizable number of senders as well. As so 
noted above, direct point-to-multipoint VCs from a 
sender to all multicast receivers within an ATM cloud 
does not seal a 

[0022] A sixth objective is to make efficient use of ATM 
capabilities. A mapping of IP multicast and RSVP over ss 
ATM should make use of ATM capabilities as much as 
possible even though some form of IP routing support 
will be required. A solution based purely on IP multicast 



routers is thus clearly undesirable. 
[0023] A seventh objective is to provide interoperabil- 
ity. A mapping should ensure interoperability with Inter 
Domain Multicast Routing (IDMR) protocols that maybe 
in use outside the ATM cloud. If the protocol used for 
multicasting within the ATM cloud is different from the 
one used outside the cloud, edge multicast switches 
should facilitate irrteroperation between the two. Sup- 
port for native ATM applications should also be provided 
since it is very likely that host end systems connected to 
an ATM network will need native ATM access as well, in 
addition to an RSVP/IP interface. 

3rief Pescription of the Praying; 

[0024] 

Fig. 1 shows a network consisting of ATM switches 

and hosts, known as an ATM cloud; 

Fig. 2 shows a network architecture for mapping IP 

multicast and Integrated Services over ATM in 

accordance with the present invention; 

Fig. 3 shows functional architecture of a Multicast 

Switch (MSW) in accordance with the present 

invention; 

Fig. 4 shows intra- and inter-LIS control VCs; 

Fig. 5 shows data VCs for multicasting within an 

LIS; 

Fig. 6 shows stage I of an example of RSVP over 
ATM; 

Fig. 7 shows stage II of an example of RSVP over 
ATM; 

Fig. 8 shows stage III of an example of RSVP over 
ATM; 

Fig. 9 is a flow chart for describing fundamental pro- 
cedures of the mapping method according to the 
present invention; 

Fig. 10 is a flow chart for describing the step SA4 in 
Fig. 9; 

Fig. 11 is a flow chart for describing the step SA5 in 
Fig. 9; and 

Fig. 12 is a flow chart for describing additional pro- 
cedures of the mapping method in Fig. 9. 

Detailed Description of the Preferred Embodiments: 

[0025] In order to understand the principles underlying 
the present inventions it is necessary to clearly define 
the problem of mapping IP multicast and Integrated 
Services over ATM. It is useful first to consider a net- 
work consisting of ATM switches and hosts, known as 
an ATM cloud, in which such a mapping is desired. An 
example network is shown in Fig. 1. All hosts and 
switches in the ATM cloud 1 need not be configured as 
IP hosts or routers. For purposes of this discussion, it 
can be assumed that some host machines are config- 
ured as IP hosts 2 and some switches 3 provide routing 
services to these IP hosts so that they can communi- 
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cate with other hosts within, as well as outside the ATM 
cloud. Designated ATM switches at the border of this 
ATM cloud may connect to non-ATM technologies such 
as Ethernet and are known as edge switches 4. IP hosts 
2A and IP routers 3A represent components of the 
external IP networks to which the ATM cloud is intercon- 
nected using the edge switches 4. Edge switches are 
required to have IP routing capabilities in order to con- 
nect the ATM cloud with other networks. Within the ATM 
cloud, it can be assumed that IP hosts are partitioned 
into logical IP subnets (LISs) 5 for administrative and 
addressing purposes. ATM Address Resolution Proto- 
col (ARP) is used to resolve IP addresses to ATM 
addresses within an LIS. See Laubach et al., Classical 
IP and ARP over ATM, Network Working Group, Internet 
Draft, Obsoletes 1577, 1622, <draft-ion-ipatm,classic2- 
03.txt) October 6, 1997. Unicast routing to other IP sub- 
nets may be provided by an IP router (possibly an IP 
switch running IP routing software) and/or by the use of 
Next Hop Resolution Protocol (NHRP) See J.V. Luciani, 
et al., NBMA next hop resolution protocol (NHRP), Inter- 
net Engineering Task Force, ION working group, Inter- 
net Draft, March 1997. 

[0026] The problem of mapping IP multicast and Inte- 
grated Services over ATM consists of adequately and 
efficiently supporting services and applications based 
on IP multicast and RSVP over an ATM cloud. In the fol- 
Jowing discussion, first the mechanism available in ATM 
standards to support IP multicasting and Integrated 
Services are outlined. Next, some issues that are 
addressed by the inventive mapping of IP multicast and 
RSVP over ATM are listed. 

Multicasting in ATM 

[0027] , The ATM Forum, which is the standardizing 
body for ATM related protocols, has included some 
more multicasting provisions in its recent specifications 
on User Network Interface (UNI). See ATM user-net- 
work interface (UNI) signaling specification version 4.0, 
The ATM Forum Technical Committee, July 1996. In the 
earlier version (3.x) of UNI, multicasting was supported 
with point-to-multipoint virtual circuits (VCs). Each such 
VC is rooted at an ATM node (multicast sender), and 
any number of leaf nodes (multicast receivers) can be 
added after the VC is established. In UNI 4.0, a provi- 
sion for leaf-initiated joins was added to point-to- 
multipoirrt VCs, thereby making the intervention of the 
root node unnecessary when leaf nodes need to be 
added to an existing point-to-multipoint VC. 
[0028] Point-to-multipoint VCs are supported in the 
current signaling specifications (version 1.0) for Private 
Network Node Interface (PNNI). See Private network- 
network interface specification version 1.0 (PNNI 1.0), 
The ATM Forum Technical Committee, March 1996. The 
next version of PNNI is also expected to support leaf-ini- 
tiated joins. Neither UNI 4.0 nor PNNI 1.0 supports 
changing the QoS parameters for a point-to-multipoint 



VC that is already established. UNI 4.0 also does not 
yet support different QoS parameter values for different 
branches in a single poirrt-to-multipoint VC. These 
restrictions make it difficult to map RSVP based multi- 
s cast to ATM point-to-multipoint VCs, since RSVP speci- 
fications allow individual receivers in the see multicast 
session to choose their own QoS parameters (i.e. pro- 
vide receiver hetesogeneity) and to change them at will 
subsequently (dynamic QoS). 

10 

Network Architecture 

[0029] Generally, the inventive network architecture 
for mapping IP multicast and Integrated Services over 

15 ATM has the following features: (1) It is suitable for both 
best effort and QoS traffic; (2) It supports intra and inter 
LIS multicasting; (3) It supports shortcut routing and 
receiver heterogeneity; and (4) It is scalable to a large 
number of senders and receivers. 

20 [0030] The inventive network architecture is based on 
an entity called a multicast switch (MSW) which can be 
thought of as an ATM switch with IP multicast routing 
capabilities. The idea is to have one MSW per LIS which 
serves the dual purpose of aggregating outside senders 

25 for local receivers and aggregating outside receivers for 
local senders. In this sense, an MSW is similar to a mul- 
ticast router, but it has additional features that make it a 
more attractive option for supporting inter LIS multicast. 
First, unlike multicast routers which sit at LIS bounda- 

30 ries (i.e. between LISs), an MSW is a part of exactly one 
LIS. Structuring MSW and LISs in this manner is more 
in line with the way ATM networks are organized where 
a bunch of end systems (hosts) connect to an ATM 
switch using a User Network Interface (UNI). Second, 

35 an MSW is capable of establishing direct VCs to other 
MSWs in the ATM cloud using ATM signaling, thus pro- 
viding shortcut routing for inter LIS multicast traffic. 
Third, an MSW can support receiver heterogeneity 
within an LIS based on the local policy and availability of 

40 resources. The following discussion first describes the 
overall network architecture and the functionality of a 
multicast switch. Thereafter, the protocol operation of IP 
multicast and RSVP in the inventive network architec- 
ture is described. 

45 [0031] As stated above, the inventive network archi- 
tecture is constituted by one multicast switch (MSW) per 
LIS in an ATM cloud. An MSW is an ATM switch which 
also runs multicast routing software in addition to sup- 
porting PNNI and UNI. Each MSW aggregates multicast 

so receivers in its US for the outside world. An MSW also 
serves as a multicast server (MCS) for its LIS. A multi- 
cast server in an ATM network allows aggregation of 
traffic from multiple senders that can be sent out on a 
single VC to the receivers. An MSW is also capable of 

55 processing RSVP control messages and performing call 
admission control (CAC) for RSVP flows. On the edges 
of the ATM cloud, border or edge MSWs help to aggre- 
gate multicast receivers inside the ATM cloud for out- 
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side senders and vice versa. An example network 
architecture is shown in Fig. 2. The figure shows an 
ATM cloud 1 that consists of three LISs (6, 7, 8). LIS 6 
and LIS 8 each have a single ATM switch that is also 
designated as the MSW 9 for its LIS. LIS 7 has two ATM s 
switches, one of which is designated as the MSW 9, 
while the other ATM switch 3 does not participate in IP 
multicasting or RSVP operation. 
[0032] It is assumed that each multicast switch (MSW) 
9 can communicate with all other MSWs in the ATM 10 
cloud using a point-to-multipoint VC. Such VCs among 
MSWs can be established using UNI signaling. If the 
ATM cloud is too large, thereby making point-to- 
multipoint VCs among MSWs impractical, a hierarchy of 
MSWs similar to the PNNI. hierarchy (See Private net- 15 
work-network interface specification version 1.0 (PNNI 
1.0), The ATM Forum Technical Committee. March 
1 996.) may be needed to cover the entire cloud. In such 
a case, a group of MSWs wfll choose a group leader 
among themselves to represent them in the next higher 20 
level group. A multicast routing scheme, albeit only for 
best effort multicast, using a PNNI hierarchy is 
described in R. Venkatswaran et al., Hierarchical multi- 
cast routing in wide-area ATM networks, Proc. Of the 
Intl. Communications Conf. (ICC '96), June, 1996. 25 

Multicast Switch (MSW) 

[0033] Fig. 3 shows the architecture of a multicast 
switch (MSW) 9. The MSW is constituted by switch zo 
hardware and a switch controller 10 that can establish 
VC translation tables for cell forwarding. Various other 
components shown in the figure are described as fol- 
lows. The RSVP message handier 1 1 terminates RSVP 
messages from other MSWs in the ATM cloud, local 35 
ATM hosts and external IP routers. The message han- 
dler also executes the RSVP protocol maintaining soft 
state for each RSVP fbw passing through the switch. 
When resource reservations for a new flow are received 
by the RSVP handler, the RSVP message handler con- 40 
suits the call admission control (CAC) function 12 to 
decide if enough resources can be reserved for the new 
flow. If so, the RSVP message handler reguests the VC 
management function 13 to take appropriate action for 
establishing intra and inter LIS VCs for the new flow. 45 
The VC management function makes use of UNI signal- 
ing function 13a to establish intra and inter LIS VCs. 
UNI signaling is used even for inter LIS VCs among 
MSWs since these VCs are terminated by the MSWs. 
The VC management function also makes use of a VC so 
concatenation function 13b that can concatenate two 
existing VCs that are currently terminated by the MSW, 
into one VC. VC management is discussed later in 
detail. 

[0034] The multicast routing component 14 of the mul- 55 
ticast switch consists of three parts. The first part 1 4a is 
responsible for maintaining group membership informa- 
tion for the LIS. Such information may be supplied by 



the local multicast address resolution server (MARS). 
See G.J. Armttage, Support for multicast over UNI 
3.0/3.1 based ATM networks, Request for comments 
2022, November 1996. The second part 14b is respon- 
sible for communicating with its peer functions running 
on other MSW in the ATM cloud. This part exchanges 
summarized local membership information with other 
MSWs. This information is used by MSWs to establish 
best effort and QoS based multicast trees among 
MSWs as explained later. The third part 14c of the mul- 
ticast routing component 14 provides an Inter Domain 
Multicast Routing (IDMR) Protocol interface to IP rout- 
ers located outside the ATM cloud. This interface con- 
sists of multicast routing code for each IDMR protocol 
supported and interacts with external routers, sending 
them multicast routing and membership information 
about the ATM cloud and receiving from them similar 
information about external networks. The IDMR inter- 
face is needed only on edge MSWs 4, shown in Fig. 2, 
since internal MSWs 9 do not communicate directly with 
outside routers. 

[0035] The steps performed in the network which ena- 
ble mapping IP multicast and Integrated Services over 
ATM networks will now be described. 

1 . Control VCs for RSVP messages 

[0036] Referring to Fig. 4. all the MSWs in an ATM 
cloud 1 (or a PNNI domain) initially form a mesh of 
point-to-multipoint control VCs 15 among themselves - 
one such VC is rooted at each MSW 9 with all other 
MSWs as its leaves. Fig. 4 shows a VC rooted at 
MSW2, with MSW1 and MSW3 as its leaves. Other 
VCs, (not shown for the sake of simplicity) are rooted at 
MSW1 and MSW3, respectively. These control VCs are 
used by the MSWs 9 to forward group membership 
information about their respective LISs to other MSWs. 
Edge MSWs 4 also forward group membership informa- 
tion learned from outside networks to other MSWs. This 
information is used by each MSW 9 to determine the set 
of MSWs that need to receive multicast data originating 
from any local sender for each multicast group. The 
control VCs 15 are also used by MSWs 9 to propagate 
PATH messages originating from senders within their 
LISs. 

[0037] RESV messages originating at multicast 
receivers within an LIS and directed towards a multicast 
sender are aggregated into a single RESV message by 
the MSW in the LIS containing the receivers, which is 
then forwarded to the MSW in the LIS containing the 
sender. Additional point-to-point control VCs may be 
created for this purpose by the MSWs as required. Con- 
trol VCs (both point-to-point and point-to-multipoint) are 
created with reasonable QoS parameters that reflect 
the amount of traffic expected on such VCs. 
[0038] Propagation of control messages from an 
MSW to the multicast receivers within its LIS is handled 
using a separate point-to-multipoint control VC 16. This 
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intra LIS control VC 16 is rooted at the MSW 9 and 
every multicast receiver in the LIS 6, 7. 8 is added to the 
control VC 16 as a leaf node when it first registers as a 
receiver with the local MARS for any multicast group. 
The intra LIS control VC is used to distribute PATH mes- 
sages from local and outside senders to local receivers. 
For sending RESV messages back to the MSW, multi- 
cast receivers use individual point-to-point control VCs 
as needed. Fig. 4 shows local control VCs 16 in each 
LIS 6, 7, 8 and also the inter LIS control VC 15 rooted at 
MSW2 9 in LIS 7. Similar inter LIS control VCs rooted at 
other MSWs are not shown for purposes of simplicity, 
through the concept just described is equally applicable. 

2. Mgltirastinq within qn LIS 

[0039] Given the network architecture described 
above, once the control VCs are established, multicast 
forwarding within each LIS is performed as follows. A 
Multicast Address Resolution Server (MARS) is 
employed in each LIS to resolve an IP multicast address 
to ATM addresses of the receivers that have joined the 
group represented by the multicast address. 
[0040] Referring to Fig. 5, in a simple multicasting sce- 
nario within an LIS 6A, receivers 17, 18 that are ATM 
hosts, and that wish to join a multicast group first regis- 
ter with the local MARS (not shown), supplying their 
.ATM addresses and the address of the multicast group. 
The MSW 9 also registers with the local MARS as a pro- 
miscuous receiver and a multicast server (MCS) for all 
IP multicast addresses. A multicast sender 19 in the LIS 
registers as a sender with the local MARS giving its own 
ATM address and the IP multicast group address to 
which it wishes to send data. The MARS returns the 
ATM address of the MSW 9 as the sole receive of the 
multicast since the MSW 9 is also the multicast server 
for the LIS 6A. The sender 19 then proceeds to estab- 
lish a best effort point-to-point VC (not shown) with the 
MSW 9 and starts sending multicast data on this VC. 
The MSW 9 in turn obtains the list of ATM hosts 17, 18 
(receivers) that have registered with the MARS as mem- 
bers of the multicast group to which the sender is send- 
ing data and establishes best effort point-to-multipoint 
data VCs 20 to those hosts. Multicast data received 
from the sender 19 is forwarded on these VCs 20 using 
shortcut routing. Any changes in the multicast group 
membership are communicated to the MSW 9 by the 
MARS. On receiving these changes, the MSW 9 adds 
leaf nodes to or removes leaf nodes from the point-to- 
multipoint best effort data VC 20 as appropriate. 
[0041 ] The MSW also forwards data packets received 
from the sender to other LISs as explained later. To ena- 
ble QoS based multicast in the LIS using RSVP, the 
sender 19 sends a PATH message to the MSW 9 on a 
separate control VC (not shown) which is forwarded by 
the MSW 9 to the local receivers 17, 18 on the intra LIS 
point-to-multipoirrt control VC (not shown). In response, 
local receivers 17 desiring QoS based multicast send 



RESV messages to the MSW 9 on individual control 
VCs (not shown) indicating their resource requirements. 
An aggregate RESV message summarizing the RESV 
messages from local receivers is sent to the sender 19 

s by the MSW 9. The sender then establishes another VC 
21 to the MSW 9 with QoS parameters derived from the 
aggregate RESV message and starts sending multicast 
data on the new VC 21 . The old best effort data VC from 
the sender to the MSW 9 is deleted. The MSW 9 also 

10 establishes a new QoS based point-to-multipoint VC 22 
to the local receivers 17 that had requested QoS serv- 
ice. These receivers are dropped from the best effort 
data VC 20, although the best effort VC 20 is left opera- 
tional to serve best effort receivers 18. The incoming 

is QoS VC 21 from the sender is concatenated to the two 
outgoing poirrt-to-murtipoint VCs 20, 22 (best effort and 
QoS based) by the MSW to ensure shortcut forwarding 
of data within the LIS. 

[0042] Using the MSW as a multicast server (MCS) 
20 has two advantages. First, multicast senders are 
relieved from the burden of managing the VC endpoints 
which keep changing due to receivers subscribing to or 
dropping off from the multicast group. Second, the MSW 
can support various features such as receiver heteroge- 
25 neity, sender aggregation, shortcut routing etc. based 
on the availability of resources and locally configured 
policy. 

3. Multicasting across LIS boundaries 

30 

[0043] Just like an IP multicast router, an MSW aggre- 
gates receivers within its LIS for outside senders and 
outside receivers for local senders. Unlike multicsst 
rooters, however, MSWs allow shortcut multicast for- 

35 warding both within and between LISs with minimal 
routing support. An inter LIS multicast tree is initially 
formed as a best effort point-to-multipoint VC rooted at 
an MSW that has a local sender, with other MSWs that 
have local receivers forming the leaf nodes. Local VCs 

40 created for multicast distribution within each LIS are 
then concatenated to this inter LIS tree thus forming the 
complete multicast tree. One such tree may be formed 
for each sender, although it may be possible to aggre- 
gate traffic from multiple senders on a single tree as 

46 well. 

[0044] To initiate QoS based multicast, a sender starts 
sending PATH messages to its local MSW. These PATH 
messages are forwarded over the intra and inter LIS 
control VCs by the senders MSW. Other MSWs, on 

so receiving the PATH messages from the sender's MSW, 
also forward them within their respective LISs. On 
receiving PATH messages, receivers can signal their 
resource requirements by sending RESV messages to 
their respective MSWs. MSWs combine the resource 

55 reservation requests from their local receivers and send 
an aggregate RESV message to the sender's MSW. 
The sender's MSW collects RESV requests from other 
MSWs and its local receivers and forwards an aggre- 
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gate request to the sender. On receiving a RESV 
request from the local MSW, a sender can upgrade its 
local data VC with the MSW to one with a QoS large 
enough to satisfy the resource reservations of all known 
receivers. After this, the MSW, in addition to establish- s 
ing a QoS tree within its LIS as mentioned earlier, 
upgrades the inter LIS best effort point-to-multipoint 
data VC with other MSWs to one with a QoS large 
enough to satisfy the QoS requirements of all the 
receivers. QoS parameters for the inter LIS data VC can w 
be obtained from the traffic specification (Tspec) param- 
eters in a sender's PATH message. Subsequently each 
MSW that is a leaf node on the inter LIS data VC also 
establishes one or more point-to-multipoint QoS VCs 
within its LIS for data distribution to QoS receivers. 75 
Unlike the intra LIS case where multiple local data VCs 
may be established for best effort and QoS receivers, 
the inter LIS multicast forwarding uses just one QoS VC. 
Thus any amount of receiver heterogeneity needed is 
supported only within individual LISs. A detailed exam- 20 
pie of RSVP operation covering inter LIS multicast is 
given later. 

4. Resource reservation 

25 

[0045] Reservations among MSWs are handled using 
ATM signaling protocols thus allowing the ATM network 
to best manage the QoS and the path for MSW-to-MSW 
point-to-multipoint VCs. Such reservations are estab- 
lished by the MSW representing a sender's LIS at the 30 
time of creating the point-to-multipoint data VC to other 
MSWs. As more receivers join in, additional MSWs can 
be added to the point-to-muttipoint VC using leaf-initi- 
ated joins. Local (intra LIS) reservations are also han- 
dled by the MSW and local senders using ATM signaling 35 
according to the local policies regarding the amount of 
heterogeneity to be supported. 

5. RSVP soft state and VC teardowp 

40 

[0046] RSVP soft state is maintained by the RSVP 
handler function of each MSW as slated earlier. RSVP 
requires routers to monitor RSVP flows using inactivity 
timers and discard the state for flows that have not seen 
any traffic for a configured amount of time. MSWs in the 45 
inventive scheme have more than just the flow related 
soft state to maintain since they also manage intra and 
inter LIS VCs. The RSVP handler function at the MSWs 
is responsible for periodically monitoring the activity on 
RSVP flows. For active flows, senders and receivers so 
should periodically send PATH and RESV messages 
respectively, but the absence of such messages for a 
configured mount of time may necessitate the RSVP 
handler to query the switch hardware for the status of 
the data traffic on the flow ff the reply from the switch ss 
hardware confirms that the flow in question has been 
inactive for a period in excess of the configured timeout, 
the state for that flow is discarded and any associated 



VCs are cleared. 

6. Multiple senders and RSVP reservation styles 

[0047] More than one sender can send data traffic to 
the same IP multicast group address at a given time. 
RSVP allows individual receivers to associate a filter 
with each requested reservation. This filter indicates 
whether the reservation applies to data sent by one 
sender (fixed filter), a list of senders (shared explicit fil- 
ter) or all current and future senders (wild card filter). 
[0048] The network architecture described here builds 
a separate multicast tree (consisting of intra and inter 
LIS VCs) for each multicast sender by default. This is 
ideal if all multicast receivers in the ATM cloud have 
requested the fixed filter style since each MSW receives 
data originating at different senders on separate VCs. 
Support for the other two styles can also be provided 
using one of the following two methods: 

i) Separate intra LIS VCs can be maintained for 
each sender by the MSW and a local receiver can 
be added to one or more of such VCs depending on 
the number of senders that match the filter style 
requested by the receiver. 

ii) Each MSW can partition the multicast receivers 
in its LIS into different groups depending upon the 
filter style and QoS parameters requested by the 
receivers. Receivers that have requested similar 
QoS parameters and the same list of senders can 
be put in one group. Next, each such group can be 
added on a different intra LIS data VC. In this man- 
ner, receivers that have requested a wild card filter 
(and similar QoS parameters) will be put on one 
data VC. Similarly, receivers that have explicitly 
requested different sets of (one or more) senders 
will be put on different data VCs. 

[0049] An MSW can be configured by the network 
administrator to use either of the above methods. 

7. External senders 

[0050] As mentioned earlier, the inner (non-edge) 
MSWs in the network architecture described here do 
not have an IDMR (inter domain multicast routing) inter- 
face. This is because such MSWs do not need to run a 
full fledged IP multicast routing protocol. The only infor- 
mation needed for establishing inter LIS VCs, which is 
about the existence of senders and receivers in each 
MSWs LIS, is exchanged among MSWs using control 
VCs. Furthermore, information needed for establishing 
intra LIS VCs is available to each MSW from its local 
MARS. Given this information, MSW can establish a 
multicast tree for each sender within the ATM cloud. 
[0051 ] If a multicast grow has an outside sender how- 
ever, the traffic originating at such a sender can reach 
more than one edge MSW If each such edge MSW cre- 
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ates a multicast tree within the ATM cloud, there may be 
multiple trees created (by different edge MSWs) for the 
same sender. Since the inner MSWs do not run a full 
fledged IP multicast routing protocol, they cannot select 
one edge switch over the other as their immediate 
source of multicast data. This can result in multiple cop- 
ies of data packets being forwarded to the receivers in 
the ATM cloud, which is clearly undesirable. To prevent 
duplication of multicast data within the ATM cloud, all 
edge MSWs in an ATM Cloud cooperate with each other 
to partition the outside senders amongst themselves. 
After such partitioning, for a given outside sender, there 
is exactly one edge MSW which forwards the data orig- 
inating at that sender into the ATM cloud. This edge 
MSW is the only one that initiates the creation of inter 
and intra LIS VCs in the ATM cloud for the outside 
sender. In this respect, the edge MSWs act in a manner 
similar to multicast routers on a shared network in Dis- 
tance Vector Multicast Routing Protocol (See D. Waitz- 
man, et al., Distance Vector Multicast Routing Protocol, 
Network Working Group, Request for Comments 1075, 
November, 1 988), where exactly one router is chosen to 
forward multicast data into the shared network for a 
given multicast source. For the edge MSWs, the whole 
ATM cloud constitutes the shared network. 

Example of RSVP Operation 

[0052] An example of RSVP operation in the inventive 
network architecture will now be described, with refer- 
ence to an ATM aloud 1 with 3 LISs as shown in Fig. 6. 
In stage I of the example operation, as shown in Fig. 6, 
there are no data VCs established in the ATM cloud. 
Although intra and inter LIS control VCs must be estab- 
lished before RSVP operation can take place, such VCs 
are omitted from the figure for clarity. The exemplary 
multicast session has one sender S 23 located in LIS2 
7. A total of three receivers 24, 25 and 27 intend to 
receive the data sent by S 23 with a certain QoS 
(assume for the sake of simplicity that all three intend to 
request the same QoS parameters). Further, receivers 
26 and 28 intend to receive the multicast data without 
any QoS reservations, i.e. with best effort protocols. In 
addition, there are RSVP receivers outside the ATM 
cloud 1 (not shown in the figure) that wish to receive the 
multicast traffic originating at the sender S 23 via two 
edge MSWs (MSW4 and MSWS) 29, 30. 
[0053] Turning now to Fig. 7, the sender S 23 first 
establishes a best effort VC 34 to MSW 32 which in turn 
establishes a best effort VC 35 to the QoS receiver 24. 
When receivers in other LISs both within and outside 
the ATM cloud 1 join the multicast group to which S 23 
is sending data, MSW 32 receives membership updates 
from the respective MSWs (e.g. 29, 30, 31, 33) indicat- 
ing the presence of local receivers in their LISs. MSW 
32 proceeds to build a point-to-multipoint best effort VC 
36 to the MSWs (e.g. 29, 30, 31, 33) that have local 
receivers. These MSWs (e.g. 29, 30, 31. 33) establish 



best effort VCs 37 in their respective LISs for distributing 
multicast traffic to local receivers (e.g. 25 - 28). All the 
MSWs 29 - 33 then concatenate the intra and inter LIS 
best effort VCs 34 - 37 to create a shortcut path from the 
5 sender S 23 to all the multicast receivers. Fig. 7 shows 
the multicast tree established in this manner, which is 
stage II in the example. 

[0054] To initiate QoS operation, the sender S 23 
sends a PATH message to MSW 32 describing its traffic 

10 characteristics. This PATH message is distributed over 
intra and inter LIS control VCs (not shown) by MSW 32. 
When other MSWs (e.g. 31 , 33) receive this PATH mes- 
sage, they in turn distribute it within their respective 
LISs (e.g. 6, 8). Edge MSWs (e.g. 29, 30), also forward 

is the PATH message to external networks. After receiving 
the PATH message, receivers 24, 25 and 27 indicate 
their desire to receive QoS traffic by sending RESV 
messages to their respective MSWs 32, 31 and 33, 
respectively. Assume that some receivers outside the 

20 ATM cloud 1 that are reachable via MSW 29 and MSW 
30 also request QoS traffic using RESV messages 
whim eventually reach MSW 29 and MSW 30. Each 
MSW (including every edge MSW) that has QoS receiv- 
ers within its LIS (or downstream from it) sends an 

25 RESV message to MSW 32 using a separate point-to- 
point control VC (not shown) summarizing the resource 
reservations requested by receivers in their respective 
LISs. Following this. MSW 32 sends an aggregate 
RESV message to S 23 indicating the reservation 

30 needed for the point-to-point VC between S 23 and 
itself. 

[0055] Turning to Fig. 8, after receiving the RESV 
message from MSW 32, the sender S 23 establishes a 
QoS VC 38 to MSW 32 and starts sending the multicast 

35 traffic over the new VC 38. S 23 also deletes the existing 
best effort VC (34 in Fig. 7). MSW 32 establishes a QoS 
VC 39 to the QoS receiver 24 and drops receiver 24 
from the existing best effort VC (35 in Fig. 7). MSW 32 
also upgrades the best effort VC (36 in Fig. 7) for inter 

40 LIS data distribution to a QoS VC 40 with QoS parame- 
ters large enough to support any of the requested reser- 
vations. There is no need to keep the existing inter 
MSW best effort VC (36 in Fig. 7) as MSWs that only 
have best effort receivers can receive data from MSW 

45 32 on the QoS VC 40 and distribute it locally over best 
effort VCs 37. The existing inter LIS best effort VC (36 
in Fig. 7) is therefore discarded and the QoS VC 40 is 
used for inter LIS data forwarding thereafter. After the 
inter MSW VC 40 is established, MSW 31 and MSW 33 

so establish QoS data VCs 41 in their respective LISs 6, 8 
to receivers that had requested QoS traffic 25, 27. The 
QoS receivers 25, 27 are also dropped from the existing 
best effort VCs (37 in Fig. 7), although best effort VCs 
may still be needed for best effort receivers. MSW2 32 

55 concatenates the incoming QoS VS 38 from the Sender 
S 23 to the outgoing inter and intra LIS VCs 39. 40. 
Other MSWs concatenate the incoming inter LIS VC 40 
to one or more outgoing intra LIS VCs 37, 41 , thus pro- 
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viding a shortcut path from the sender to all multicast 
receivers (both QoS and best effort). The final VC setup 
(stage III) is shown in Fig. 8. 

Supported Features s 

[0056] The network architecture for mapping IP multi- 
cast and Integrated Services over ATM just described 
supports a variety of features. 

[0057] First, receiver heterogeneity, i.e. allowing differ- 
ent receivers in the same multicast session to receive 
data with different reservations, can be supported by an 
MSW in many forms including the modified homogene- 
ity approach recommended in Crawley et al., A Frame- 
work for Integrated Services and RSVP over ATM, 
Internet Engineering Task Force, Internet Draft <draft- 
ietf-issll-atm-framework-00.txt). July 24, 1997. 
Receiver heterogeneity is supported only within LISs 
where it can be easily controlled by local polio and avail- 
ability of resources. It is possible to support full hetero- 
geneity, i.e. distinct QoS VCs for receivers with different 
reservations, provided sufficient resources are availa- 
ble. The number of distinct VCs to be supported for a 
given multicast address can thus be tied to the amount 
of available resources such as buffer space and VC 
numbers at the local MSW etc. Supporting receiver het- 
erogeneity at the MSW may require different queues 
and algorithms to manage these queues for different 
outgoing VCs if they are being fed from a single incom- 
ing VC. It is desirable to have this capability in ATM 
switch hardware, although it is always possible to sup- 
port receiver heterogeneity in software by reassembling 
an incoming packet and transmitting it over several out- 
going VCs with different QoS. Supporting receiver het- 
erogeneity only at the LIS level saves the trouble of 
establishing and maintaining multiple multicast trees 
(one for each QoS class requested) for the same ses- 
sion that may potentially span the whole ATM cloud. 
Consequently, there is no need to send duplicate copies 
of data packets over multiple VCs between MSWs. 
Instead, message duplication if any, is confined within 
the LIS boundaries. As a matter of fact, if an LIS con- 
sists of just one ATM switch (which must be the MSW), 
only one copy of data is forwarded on any ATM link even 
with full receiver heterogeneity since the lid between an 
ATM host and its switch is a point-to-point link and not a 
shared network. 

[0058] Second, shortcut routing from a multicast 
sender to all the receivers in the ATM cloud can be 
accomplished by simply concatenating the following 
separate VCs - i) the point-to-point VC from the sender 
to its local MSW, ii) the point-to-multipoint inter LIS VC 
from the sender's MSW to other MSWs that have local 
receivers, and in) the point-to-multipotnt VCs between 
the MSW and local receivers in each LIS that has multi- 
cast receivers. An MSW can concatenate the VCs in 
this manner after receiving a VC setup request from the 
upstream direction (another MSW or a local sender) 



and initiating a VC setup in the downstream direction (to 
other MSWs or local receivers). Alternatively, the con- 
catenation can be performed when the first data packet 
traverses through the MSW on the routed path in a way 
similar to IP switching schemes. Using VC concatena- 
tion for shortcut routing and direct VCs for inter MSW 
data and control traffic ensures shortcut routing from a 
sender to all the receivers in the ATM cloud. At the same 
time this arrangement makes sure that RSVP control 
messages traverse the same path as data (although not 
the same VC) thus allowing RSVP PATH messages to 
correctly accumulate path characteristics from a sender 
to the receivers. 

[0059] Third, edge MSWs on the border of the ATM 
cloud ensure interoperation with Inter Domain Multicast 
Routing (IDMR) protocols that may be in use outside the 
ATM cloud. An edge MSW behaves as any other MSW 
within the ATM cloud - in fact it may even support its own 
LIS of ATM hosts. In addition, an edge MSW also runs 
appropriate multicast routing software to correctly inter- 
operate with the routing protocol being used on its non- 
ATM side. 

[0060] Fourth, RSVP allows receivers to change their 
QoS reservations at any time even after a multicast ses- 
sion has been established. It is somewhat difficult to 
support dynamic QoS in ATM networks, however, since 
neither UNI 4.0 nor PNNI currently supports changing 
QoS parameters once a VC has been established. The 
only possible way to change QoS for an existing data 
VC in the ATM network is to establish a new VC with the 
modified QoS parameters and migrate traffic from the 
old VC to the new one. For a sufficiently large multicast 
tree, such changes can be quite costly since many of 
the requested QoS changes will propagate beyond the 
LIS of the receiver that requested the QoS change. In 
the inventive scheme, which has separate VCs for intra 
and inter LIS traffic, most requests for changing QoS 
can be accommodated locally, i.e. within the LIS of the 
host that requested the change, because the inter LIS 
data VC for a given data flow is established with a suffi- 
ciently large QoS so that it can accommodate a whole 
range of QoS requests from individual receivers. 
Requests for changes in QoS by local receivers may 
thus cause establishment of additional VCs (and possi- 
bly removal of old VCs) to support the new QoS but 
such changes will be limited to the LIS. 
[0061 ] Referring to Fig. 9, the description will be made 
as regards fundamental procedures of the mapping 
method according to the present invention. 
[0062] The mapping method is for mapping quality of 
service based internetworking protocol (IP) multicast in 
a network architecture. The IP multicast supports at 
least one multicast group. The network architecture 
comprises an asynchronous transfer mode (ATM) cloud 
including a plurality of logical IP subnets, a plurality of 
multicast switches and a plurality of local ATM hosts. 
The multicast switches communicates by the use of 
ATM protocols. One of the plurality of multicast switches 
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is located in each of the logical IP subnets. At least one 
of the local ATM hosts is located in each of the logical IP 
subnets. 

[0063] At a step SA1 , an intra logical IP subnet control 
tree is formed in each of the logical IP subnets for com- 
munication between the multicast switches and the ATM 
hosts. At a step SA2, an inter logical IP subnet control 
tree is formed for providing shortcut routing for inter log- 
ical IP subnet multicast traffic and for each of the at least 
one multicast group. At step SA3, a best effort point is 
formed to point data virtual circuit between one of the 
ATM hosts sending multicast data and one of the multi- 
cast switches located in one of the logical IP subnets in 
which the one of the ATM hosts sending multicast data 
is disposed. At step SA4, a best effort intra logical IP 
subnet data tree is formed in each of the logical IP sub- 
nets. At step SA5, a best effort inter logical IP subnet 
data tree is formed, wherein the best effort inter logical 
IP subnet data tree may be concatenated with the best 
effort intra logi cal IP subnet data trees, thereby forming 
shortcuts through the multicast switches for routing inter 
logical IP subnet multicast traffic. At step SA6, at least 
one branch of at least one of the best effort intra logical 
IP subnet data trees is upgraded in the logical IP sub- 
nets to be a quality of service intra logical IP subnet 
data tree for transmitting multicast data. At step SA7, 
the best effort inter logical IP subnet data tree is 
.upgraded to a quality of service inter logical IP subnet 
data tree for transmitting multicast data. At step SA8, 
the quality of service intra logical IP subnet data trees is 
concatenated with the quality of service inter logical IP 
subnet data tree and any remaining of the best effort 
intra logical IP subnet data trees, thereby forming a 
quality of service based multicast tree. 
[0064] In the mapping method, it is preferable that the 
step SA1 comprise a step of establishing point to 
multipoint control virtual circuits within each of the logi- 
cal IP subnets using ATM signaling, between the multi- 
cast switches and the local ATM hosts disposed in each 
of the logical IP subnets. 

[0065] Preferably, the step SA2 further comprises a 
step of establishing point to multipoint control virtual cir- 
cuits between the multicast switches located in each of 
the logical IP subnets using ATM signaling. 
[0066] Referring to Fig. 1 0, it is preferable that the step 
SA4 comprises a step SA41 of determining sets of the 
local ATM hosts in the logical IP subnets as being mem- 
bers of one of the at least one multicast group, and a 
step SA42 of establishing best effort point to multipoint 
data virtual circuits within each of the logical IP subnets 
for each of the at least one multicast group using ATM 
signaling from a respective one of the multicast 
switches in each of the logical IP subnets to each of the 
local ATM hosts which are determined to be members 
of the one of the at least one multicast group. 
[0067] Referring to Fig. 1 1 , the step SA5 further com- 
prises a step SA51 of forwarding group membership 
information regarding the at least one multicast group 



from each of the multicast switches regarding its logical 
IP subnet to others of the multicast switches, a step 
SA52 of making each of the multicast switches deter- 
mine by the use of the group membership information 
5 and a specific set of others of the multicast switches 
need to receive multicast data originating from any of 
the local ATM hosts sending multicast data, and a step 
SA53 of establishing a best effort point to multipoint 
data virtual circuit from the one of the multicast switches 
to disposed in one of the logi cal IP subnets containing one 
of the ATM hosts sending multicast data to others of the 
multicast switches disposed in the logical IP subnets 
containing ones of the ATM hosts receiving multicast 
data using ATM signaling. 
75 [0068] Referring to Fig. 12, the mapping step further 
comprises a step SB1 of, after the step SA5, transmit- 
ting a source description control massage from the one 
of the ATM hosts sending multicast data, over a first 
point to point control virtual circuit established between 
20 the one of the ATM hosts sending multicast data and the 
one of the multicast switches located in the one of the 
logical IP subnets in which the one of the ATM hosts 
sending multicast data is disposed, a step SB2 of for- 
warding the source description control message from 
25 the multicast switch in the logical IP subnet of the one of 
the ATM hosts sending multicast data to others of the 
multicast switches over the inter logical IP subnet con- 
trol tree, and a step SB3 of making the others of the 
multicast switches forward the source description con- 
30 trol message over the intra logical IP subnet control tree 
to others of the ATM hosts receiving multicast data. 
[0069] It is preferable that the mapping method further 
comprises a step SB4 of, after the step SB3, making the 
multicast switches receive quality of service resource 
35 reservation request control messages over second 
ones of point to point control virtual circuits, from ones 
of the ATM hosts receiving multicast data and desiring 
quality of service based multicast in the logical IP sub- 
nets, wherein each of the messages is capable of indi- 
40 eating a different quality of service, the multicast 
switches aggregating the quality of service resource 
reservation request control messages-j forming aggre- 
gate quality of service resource reservation request 
control messages, the quality of service resource reser- 
45 vation request control messages indicating resource 
requirements from the ones of the ATM hosts receiving 
multicast data, and a step SB5 of making the multicast 
switches transmit the aggregate quality of service 
resource reservation request control messages over 
so third ones of point to point control virtual circuits to the 
multicast switch in the logical IP subnet of the one of the 
ATM hosts sending multicast data , the third ones point 
to point control virtual circuits being formed for transmit- 
ting the aggregate quality of service resource reserva- 
55 tion control messages, the one of the multicast switches 
aggregating and forwarding the quality of service 
resource reservation request control messages to the 
one of the ATM hosts sending data, over the first point to 
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point control virtual circuit. The quality of service 
resource reservation control messages is used in the 
step SA6. 

[0070] The mapping method further comprises the 
step of upgrading the best effort point to point data vir- 
tual circuit to a quality of service point to point data vir- 
tual circuit Preferably, the aggregate quality of service 
resource reservation control messages is used in the 
steps SA7 and SA3. 

[0071 ] It is preferable that the mapping method further 
comprises a step SB6 of transmitting hew quality of 
service resource reservation request control messages 
from ones of the receivers to respective ones of the mul- 
ticast switches to change the quality of service based 
multicast tree, a step SB7 of changing at least some 
branches of the quality of service intra logical IP subnet 
data trees to new quality of service intra logical IP sub- 
net data trees for transmitting multicast data using ATM 
signaling, the upgrading being based on the new quality 
of service resource reservation request control mes- 
sages, and a step SB8 of concatenating the new quality 
of service intra logical IP subnet data trees with the 
quality of service intra logical IP subnet data trees, the 
quality of service inter logical IP subnet tree and the any 
remaining of the beet effort intra logical IP subnet data 
trees, thereby forming a new quality of service based 
multicast tree. 

[0072] Preferably, the mapping method further com- 
prises the step of making each of the multicast switches 
determine, using group membership information 
regarding the at least one multicast group, a specific set 
of others of the multicast switches needing to receive 
multicast data originating from any of the local ATM 
hosts sending multicast data for each of the at least one 
multicast group. 

[0073] It is preferable that the the ATM cloud further 
comprises a plurality of multicast address resolution 
servers and that at least one of the multicast address 
resolution servers is located in each of the logical IP 
subnets. At the step SA4 in this case, ones of the ATM 
hosts receiving multicast data are registered with the 
multicast address resolution servers when the ones of 
the ATM hosts receiving multicast data wish to join one 
of the at least one multicast group. The multicast 
address resolution servers resolve an IP multicast 
address to an ATM address for each of the ones of the 
ATM hosts receiving multicast data. The multicast 
switches are registered with the multicast address reso- 
lution servers as promiscuous receivers and as multi- 
cast servers for all IP multicast addresses. 
[0074] It is preferable that one of the ATM hosts send- 
ing multicast data registers as a sender with one of the 
multicast address resolution servers located in one of 
the logical IP subnets containing the sender, that the 
sender provides the sender's ATM address and one of 
the IP multicast addresses to which the sender wishes 
to send the multicast data, and that the one of the mul- 
ticast address resolution servers returns an ATM 



address of the one of the local multicast switches 
located in the one of the logical IP subnets containing 
the sender as a sole receiver of the one of the at least 
one multicast group. 

5 [0075] In addition, it is preferable that changes in 
membership of the one of the at least one multicast 
groip are communicated to the multicast switches by 
the multicast address resolution servers and that the 
multicast switches add and remove virtual circuits to the 

10 ones of the ATM hosts receiving multicast data accord- 
ing to the changes in membership of the one of the at 
least one multicast group. 

[0076] Preferably, upgraded ones of the at least one 
branch are removed after the step SA6, 

15 Quality of service parameters of the quality of service 
inter logical IP subnet data trees is sufficiently large to 
accommodate one of the quality of service resource 
reservation request control messages having a largest 
quality of service requirement. 

20 [0077] Preferably, the mapping method further com- 
prises the step of detecting an absence of the source 
description control message and the quality of service 
resource reservation request control messages for a 
predetermined period of time and deleting conrespond- 

25 ing ones of the quality of service intra IP logical subnet 
data trees after the predetermined period of time has 
elapsed. 

[0078] Preferably, the mapping method further com- 
prises the step of interoperating with protocols outside 
30 of the ATM cloud through edge switches. In this case, 
the edge switches are multicast switches and disposed 
at edges of the ATM cloud. 

[0079] Preferably, the edge switches forward group 
information learned from outside networks to the multi- 

35 cast switches in the ATM cloud. 

[0080] In the mapping method, it becomes possible 
that additional ones of the ATM hosts send multicast 
data begin sending multicast data to one of the at least 
one multicast group, thereby allowing the one of the 

40 ATM hosts sending multicast data and the additional 
ones of the ATM hosts sending multicast data to send 
the multicast data to a single IP multicast group address 
at a given time. 

[0081] The quality of service resource reservation 
45 request control messages generated by the ones of the 
ATM hosts receiving multicast data, further includes a 
filter. The filter indicates the quality of service resource 
reservation request control messages apply to data 
sent by one of all current and future ones of the send- 
so ers, a specific list of the senders and a fixed one of the 
senders. When the filter indicates that the quality of 
service resource reservation request control messages 
apply to a fixed one of the senders, a separate quality of 
service based multicast tree is formed for the fixed one 
55 of the senders. 

[0082] Additional intra logical IP subnet quality of 
service based multicast trees are formed for each of the 
additional ones of the ATM hosts sending multicast 
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data. The receivers are added to the additional intra log- 
ical IP subnet quality of service based multicast trees 
based upon the fitter. 

[0083] The receivers are partitioned into groups. The 
groups group ones of the receivers based upon same s 
ones of the quality of service resource reservation 
request control messages and same ones of the filter. 
Each of the groups operates on a separate multicast 
tree. 

[0084] The edge switches cooperate in determining a io 
given one of the edge switches to be associated with a 
given outside sender disposed outside the ATM cloud. 
The given one of the edge switches initiates inter logical 
IP subnet virtual circuits and intra logical IP subnet vir- 
tual circuits in said ATM cloud for said given outside is 
sender. 

[0085] Although the present invention has been 
described with reference to a specific embodiment, 
many modifications and variations therein will be readily 
apparent to those of working skill in this technological 20 
field. Accordingly, all such variations and modifications 
are included within the scope of the present invention as 2. 
defined by the following claims. 

Claims 25 

1. A method for mapping quality of service based 
.. internetworking protocol (IP) multicast in a network 
architecture, said IP multicast supporting at least 
one multicast group, said network architecture com- 30 
prising an asynchronous transfer mode (ATM) 
cloud including a plurality of logical IP subnets, a 3. 
plurality of multicast switches and a plurality of local 
ATM hosts, said multicast switches communicating 
using ATM protocols, wherein one of said plurality 35 
of multicast switches is located in each of said logi- 
cal IP subnets and at least one of said local ATM 
hosts is located in each of said logical IP subnets, 
said method comprising the steps of: 

40 

forming an intra logical IP subnet control tree in 4. 
each of said logical IP subnets for communica- 
tion between said multicast switches and said 
ATM hosts; 

forming an inter logical IP subnet control tree 46 
for providing shortcut routing for inter logical IP 
subnet multicast traffic; and for each of said at 
least one multicast group; 
forming a best effort point to point data virtual 
circuit between one of said ATM hosts sending so 
multicast data and one of said multicast 
switches located in one of said logical IP sub- 
nets in which said one of 6aid ATM hosts send- 
ing multicast data is disposed; 
forming a best effort intra logical IP subnet data ss 
tree in each of said logical IP subnets; 
forming a best effort inter logical IP subnet data 5. 
tree, wherein said best effort inter logical IP 



subnet data tree may be concatenated with 
said best effort intra logical IP subnet data 
trees, thereby forming shortcuts through said 
multicast switches for routing inter logical IP 
subnet multicast traffic; 

upgrading at least one branch of at least one of 
said best effort intra logical IP subnet data 
trees in said logical IP subnets to be a quality of 
service intra logical IP subnet data tree for 
transmitting multicast data; 
upgrading said best effort inter logical IP sub- 
net data tree to a quality of service inter logical 
IP subnet data tree for transmitting multicast 
data; 

concatenating said quality of service intra logi- 
cal IP subnet data trees with said quality of 
service inter logical IP subnet data tree and 
any remaining of said best effort intra logical IP 
subnet data trees, thereby forming a quality of 
service based multicast tree. 

Tiie method according to claim 1 , wherein said step 
of forming an intra logical IP subnet control tree in 
each of said logical IP subnets comprises: 

establishing point to multipoint control virtual 
circuits within each of said logical IP subnets 
using ATM signaling, between said multicast 
switches and said local ATM hosts disposed in 
each of said logical IP subnets 

The method according to claim 1 , wherein said step 
of forming an inter logical IP subnet control tree fur- 
ther comprises: 

establishing point to multipoint control virtual 
circuits between said multicast switches 
located in each of said logical IP subnets using 
ATM signaling. 

The method according to claim 1 , wherein said step 
of forming a best effort intra logical IP subnet data 
tree comprises: 

determining sets of said local ATM hosts in said 
logical IP subnets as being members of one of 
said at least one multicast group; 
establishing best effort point to multipoint data 
virtual circuits within each of said logical IP 
subnets for each of said at least one multicast 
group using ATM signaling from a respective 
one of said multicast switches in each of said 
logical IP subnets to each of said local ATM 
hosts which are determined to be members of 
said one of said at least one multicast group. 

The method according to claim 1, wherein said step 
of forming a best effort inter logical IP subnet data 
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tree further comprises: 

forwarding group membership information 
regarding said at least one multicast group 
from each of said multioast switches regarding s 
its logical IP subnet to others of said multicast 
switches; 

each of said multicast switches determining, 
using said group membership information, a 
specific set of others of said multicast switches 10 
needing to receive multicast data originating 
from any of said local ATM hosts sending multi- 
cast data; and 

establishing a best effort point to multipoint 
data virtual circuit from said one of said mufti- is 
cast switches disposed in one of said logical IP 
subnets containing one of said ATM hosts 
sending multicast data to others of said murti- 
. cast switches disposed in said logical IP sub- 
nets containing ones of said ATM hosts 20 
receiving multicast data using ATM signaling. 

6. The method according to claim 1 , further compris- 
ing the steps of: 

25 

after said step of forming a best effort inter log- 
ical IP subnet data tree, transmitting a source 
description control message from said one of 
said ATM hosts sending multicast data, over a 
first point to point control virtual circuit estab- so 
lished between said one of said ATM hosts 
sending multicast data and said one of said 
multicast switches located in said one of said 
logical IP subnets in which said one of said 
ATM hosts sending multicast data is disposed; 35 
forwarding said source description control 
message from said multicast switch in said log- 
ical IP subnet of said one of said ATM hosts 
sending multicast data to others of said multi- 
cast switches over said inter logical IP subnet 40 
control tree; and 

said others of said multicast switches forward- 
ing said source description control message 
over said intra logical IP subnet control tree to 
others of said ATM hosts receiving multicast 45 
data. 

7. The method according to claim 6, further compris- 
ing the steps of: 

so 

after said step of others of said multicast 
switches forwarding said source description 
control message, said multicast switches 
receiving quality of service resource reserva- 
tion request control messages over second ss 
ones of point to point control virtual circuits, 
from ones of said ATM hosts receiving multi- 
cast data and desiring quality of service based 



multicast in said logical IP subnets, wherein 
each of said messages is capable of indicating 
a different quality of service, said multicast 
switches aggregating said quality of service 
resource reservation request control mes- 
sages, forming aggregate quality of service 
resource reservation request control mes- 
sages, said quality of service resource reserva- 
tion request control messages indicating 
resource requirements from said ones of said 
ATM hosts receiving multicast data; and 
said multicast switches transmitting said aggre- 
gate quality of service resource reservation 
request control messages over third ones of 
point to point control virtual circuits to said mul- 
ticast switch in said logical IP subnet of said 
one of said ATM hosts sending multicast data, 
said third ones point to point control virtual cir- 
cuits being formed for transmitting said aggre- 
gate quality of service resource reservation 
control messages, said one of said multicast 
switches aggregating and forwarding said qual- 
ity of service resource reservation request con- 
trol messages to sard one of said ATM hosts 
sending data, over said first point to point con- 
trol virtual circuit. 

8. The method according to claim 7, wherein said 
quality of service resource reservation control mes- 
sages are used in said step of upgrading said at 
least one branch of at least one of said best effort 
intra logical IP subnet data trees. 

9. The method according to claim 7, further compris- 
ing the step of: 

upgrading said best effort point to point data 
virtual circuit to a quality of service point to 
point data virtual circuit, wherein said aggre- 
gate quality of service resource reservation 
control messages are used in said step of 
upgrading said best effort inter logical IP sub- 
net data tree and said step of upgrading said 
best effort point to point data virtual circuit. 

10. The method according to claim 7, further compris- 
ing the steps of: 

transmitting new quality of service resource 
reservation request control messages from 
ones of said receivers to respective ones of 
said multicast switches to change said quality 
of service based multicast tree; 
changing at least some branches of said qual- 
ity of service intra logical IP subnet data trees 
to new quality of service intra logical IP subnet 
data trees for transmitting multicast data using 
ATM signaling, said upgrading being based on 
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said new quality of service resource reserva- 
tion request control messages; and 
concatenating said new quality of service intra 
logical IP subnet data trees with said quality ol 
service intra logical IP subnet data trees, said 
quality of service inter logical IP subnet tree 
and said any remaining of said best effort intra 
logical IP subnet data trees, thereby forming a 
new quality of service based multicast tree. 

11. The method according to claim 3. further compris- 
ing the steps of : 

each of said multicast switches determining, 
using group membership information regarding 
said at least one multicast group, a specific set 
of others of said multicast switches needing to 
receive multicast data originating from any of 
said local ATM hosts sending multicast data for 
each of said at least one multicast group. 

12. The method according to claim 4, wherein said ATM 
cloud further comprises a plurality of multicast 
address resolution servers, at least one of said mul- 
ticast address resolution servers being located in 
each of said logical IP subnets, said step of deter- 
mining sets further comprising the steps of: 

registering ones of said ATM hosts receiving 
multicast data with said multicast address res- 
olution servers when said ones of said ATM 
hosts receiving multicast data wish to join one 
of said at least one multicast group, said multi- 
cast address resolution servers resolving an IP 
multicast address to an ATM address for each 
of said ones of said ATM hosts receiving multi- 
cast data; and 

registering said multicast switches with said 
multicast address resolution servers as promis- 
cuous receivers and as multicast servers for all 
IP multicast addresses. 

13. The method according to claim 12, wherein one of 
said ATM hosts sending multicast data registers as 
a sender with one of said multicast address resolu- 
tion servers located in one of said logical IP subnets 
containing said sender, said sender providing said 
sender's ATM address and one of said IP multicast 
addresses to which said sender wishes to send 
said multicast data, said one of said multicast 
address resolution servers returning an ATM 
address of said one of said local multicast stitches 
located in said one of said logical IP subnets con- 
taining said sender as a sole receiver of said one of 
said at least one multicast group. 

14. The method according to claim 12, wherein 
changes in membership of said one of said at least 
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one multicast group are communicated to said mul- 
ticast switches by said multicast address resolution 
servers, said multicast switches adding and remov- 
ing virtual circuits to said ones of said ATM hosts 
receiving multicast data according to said changes 
in membership of said one of said at least one mul- 
ticast group. 

1 5. The method according to claim 1 , wherein after said 
step of upgrading at least one branch of at least one 
of said best effort intra IP logical subnet trees to 
quality of service intra logical IP subnet data trees, 
upgraded ones of said at least one branch are 
removed. 

1 6. The method according to claim 9, wherein quality of 
service parameters of said quality of service inter 
logical IP subnet data trees are sufficiently large to 
accommodate one of said quality of service 
resource reservation request control messages 
having a largest quality of service requirement. 

17. The method according to claim 7 further comprising 
the step of detecting an absence of said source 
description control message and said quality of 
service resource reservation request control mes- 
sages for a predetermined period of time and delet- 
ing corresponding ones of said quality of service 
intra IP logical subnet data trees after said prede- 
termined period of time has elapsed. 



18. The method according to claim 1, further compris- 
ing interoperating with protocols outside of said 
ATM cloud through edge switches, said edge 
switches being multicast switches and disposed at 
edges of said ATM cloud. 

19. The method according to claim 18, wherein said 
edge switches forward group information learned 
from outside networks to said multicast switches in 
said ATM cloud. 

20. The method according to claim 13, wherein addi- 
tional ones of said ATM hosts sending multicast 
data begin sending multicast data to one of said at 
least one multicast group, thereby allowing said one 
of said ATM hosts sending multicast data and said 
additional ones of said ATM hosts sending multicast 
data to send said multicast data to a single IP mul- 
ticast group address at a given time. 

21. The method according to claim 7, wherein said 
quality of service resource reservation request con- 
trol messages generated by said ones of said ATM 
hosts receiving multicast data, further include a fil- 
ter, said filter indicating said quality of service 
resource reservation request control messages 
apply to data sent by one of all current and future 
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ones of said senders, a specific list of said senders 
and a fixed one of said senders. 

22. The method according to claim 21, wherein when 
said filter indicates that said quality of service 
resource reservation request control messages 
apply to a fixed one of said senders, a separate 
quality of service based multicast tree is formed for 
said fixed one of said senders. 

23. The method according to claim 21 , wherein addi- 
tional intra logical IP subnet quality of service 
based multicast trees are formed for each of said 
additional ones of said ATM hosts sending multicast 
data, said receivers being added to said additional 
intra logical IP subnet quality of service based mul- 
ticast trees based upon said filter. 

24. The method according to claim 21, wherein said 
receivers are partitioned into groups, said groups 
grouping ones of said receivers based upon same 
ones of said quality of service resource reservation 
request control messages and same ones of said 
filter, each of said groups operating on a separate 
multicast tree. 

25. The method according to claim 19, wherein said 
edge switches cooperate in determining a given 
one of said edge switches to be associated with a 
given outside sender disposed outside said ATM 
cloud, said given one of said edge switches initiat- 
ing inter logical IP subnet virtual circuits and intra 
logical IP subnet virtual circuits in said ATM cloud 
for said given outside sender. 

26. A network architecture for mapping quality of serv- 
ice based internetworking protocol (IP) multicast in 
a network, said IP multicast supporting at least one 
multicast group, said network architecture compris- 
ing an asynchronous transfer mode (ATM) cloud, 
said ATM cloud comprising: 

a plurality of logical IP subnets; 
a plurality of ATM hosts, wherein at least one of 
said plurality of ATM hosts is disposed in each 
of said logical IP subnets; and 
a plurality of multicast switches, wherein each 
of said plurality of multicast switches is dis- 
posed in a respective one of said logical IP 
subnets, for aggregating senders outside each 
of said logical IP subnets for local receivers 
inside each of said logical IP subnets and 
aggregating receivers outside each of said log- 
ical IP subnets for local senders inside each of 
said logical IP subnets, said multicase switches 
communicating with each other using ATM pro- 
tocols. 



27. A network architecture according to claim 26, 
wherein said ATM cloud further comprises: 

a plurality of multicast address resolution serv- 
5 ers, wherein one of said plurality of multicast 

address resolution servers is located in each of 
said logical IP subnets for resolving an IP mul- 
ticast address to ATM addresses of receivers 
joining one of said at least one multicast group 
w represented by a multicast address. 

28. A network architecture according to claim 27 further 
comprising edge switches for aggregating ones of 
said ATM hosts receiving multicast data inside said 

15 ATM cloud, for senders outside said ATM cloud and 
aggregating receivers outside said ATM cloud for 
ones of said ATM hosts sending multicast data 
inside said ATM cloud, said edge switches being 
ones of said multicast switches disposed at edges 

20 of said ATM cloud. 

29. A network architecture according to claim 28, 
wherein said edge switches interoperate with inter 
domain multicast routing (IDMR) protocols used 

25 outside sab ATM cloud for sending and receiving 
multicast route and membership information about 
said ATM cloud. 

30. A network architecture according to claim 29, 
30 wherein for each of said senders outside said ATM 

cloud, only one of said edge switches establishes a 
multicast tree within said ATM cloud. 

31. In a network architecture for mapping internetwork- 
's ing protocol (IP) multicast and integrated services 

over an asynchronous transfer mode (ATM) net- 
work, said network architecture comprising an ATM 
cloud including a plurality of multicast switches and 
local ATM hosts, said ATM cloud further including a 

40 plurality of logical IP subnets, each of said logical IP 
subnets containing one of said multicast switches 
and at least one of said local ATM hosts, said multi- 
cast switches communicating with each other using 
ATM protocols, wherein each of said multicast 

45 switches comprises: 

switching fabric allowing incoming virtual cir- 
cuits to feed multiple outgoing virtual circuits; 
a switch controller for controlling said switching 
so fabric to establish header translation tables for 

said virtual circuits; 

an ATM signaling software module for estab- 
lishing said virtual circuits using ATM signaling, 
said switch controller being capable of termi- 
55 nating said virtual circuits and concatenating 

said virtual circuits on two different links, 
thereby allowing data on one of said incoming 
virtual circuits to be forwarded by said switch- 
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ing fabric on one of said outgoing virtual cir- 
cuits without software intervention; and 
a multicast routing module, including a module 
for maintaining group membership information 
for said logical IP subnets, and a module for 
communicating with peer functions on said 
multicast switches in said ATM cloud for 
exchanging summarized local membership 
information. 

32. A network architecture according to claim 31. 
wherein said multicast switches further comprise: 

a resource reservation protocol message han- 
dling module for terminating resource reserva- 
tion control messages from said multicast 
switches in said network architecture and from 
said local ATM hosts; 

a call admission control module connected to 
said resource reservation protocol message 
handling module for determining if sufficient 
resources may be reserved for a new data flow 
when said resource reservation protocol mes- 
sage handling module receives a resource res- 
ervation for said new data flow; and 
a virtual circuit management module for estab- 
lishing virtual circuits for said new flow when 
said call admission control module determines 
sufficient resources may be reserved. 

33. A network architecture according to claim 32, 
wherein said virtual circuit management module 
comprises a first part for establishing intra logical IP 
subnet virtual circuits and inter logical IP subnet vir- 
tual circuits and a second part for concatenating 
any two of said intra logical IP subnet virtual circuits 
and said inter logical IP subnet virtual circuits into 
one virtual circuit, said two virtual circuits terminat- 
ing in a respective one of said multicast switches, 
said intra logical IP subnet virtual circuits and inter 
logical IP subnet virtual circuits forming a multicast 
tree among said multicast switches. 

34. A network architecture according to claim 33, 
wherein said multicast tree is one of a best effort 
based multicast tree, a quality of service based 
multicast tree or a mixed best effort and quality of 
service based multicast tree. 

35. A network architecture according to claim 33, 
wherein said virtual circuit management module 
adds ones of said ATM hosts receiving multicast 
data as leaf nodes to said multicast tree when said 
ones of said ATM hosts receiving multicast data join 
said multicast tree. 

36. A network architecture according to claim 35, 
wherein said virtual circuit management module 



adds new ones of said multicast switches to said 
multicast tree when said new ATM hosts join said 
multicast tree. 

s 37. A network architecture according to claim 33, 
wherein said virtual circuit management module 
removes ones of said ATM hosts receiving multicast 
data as leaf nodes from said multicast tree when 
said ones of said ATM hosts receiving multicast 

10 data leave a data flow. 

38. A network architecture according to claim 37. 
wherein said virtual circuit management module 
removes ones of said multicast switches from said 
is multicast tree when all ones of said ATM hosts 
receiving multicast data disposed in corresponding 
ones of said logical IP subnets containing said ones 
of said multicast switches are removed. 

20 39. A network architecture according to claim 32, 
wherein at least one of said multicast switches is an 
edge switch for aggregating ones of said ATM hosts 
receiving multicast data inside said ATM cloud for 
hosts being senders outside said ATM cloud, and 

25 aggregating hosts being receivers outside said 
ATM cloud for ones of said ATM hosts sending mul- 
ticast data inside said ATM cloud. 

40. A network architecture according to claim 39, 
30 wherein said multicast routing module further com- 
prises a module for providing an inter domain multi- 
cast routing (IDMR) protocol interface to IP routers 
located outside said ATM cloud. 

35 41. A network architecture according to claim 40, 
wherein said inter domain multicast routing (IDMR) 
protocol interface comprises multicast routing for 
supported IDMR protocols for interacting with said 
IP routers outside said ATM cloud by sending and 

40 receiving multicast route and membership informa- 
tion about said ATM cloud. 
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A SYSTEM MODEL FOR RSVP OVER ATM MAPPING 

FIG.1 



19 



EP0 917390A2 




EP0917 390A2 



ca 

CO 

S 

a. 
tu 

X 



Z« 
(Till 

ill 1 — OT 

xo < 
tua: 2 



7* < 't 



INTER LIS 
ROUTING 


IDMR 

INTERFACE 


GROUP 
MEMBERSHIP 








































so: 






CO CO 





z 




o 








5e 




z 




Ul 








5E 




o 




z 




o 


Z 


a 


Ui 




o 


Hi 


> 


O 
< 


o 


z 


z 


< 






< 


OA 


IGN 




CO 








3 



T 

€0 
CO 



0£ 
UJ 

•J 

o 
a: 



o 
a 

x 

o 

CO 



5 

CO 



o 

CO 

I— 

CO 

< 



= CO 

< CD 



Ui 

=> 
)- 



o 
a: 
< 



a 
z 



Oui 



21 



EP 0 917 390 A2 



7 




INTER LIS CONTROL VC FOR MSWs 

INTRA AND INTER LIS CONTROL VCs 

FIG. 4 
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FIG. 5 
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RSVP OVER ATM EXMAPLErSTAGE 1 

FIG. 6 
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LOCAL BEST-EFFORT DATA VCs FOR USs 



MSW-TO-MSW BEST EFFORT DATA VC 

RSVP OVER ATM EXAMPLE:STA6E 2 

FIG. 7 
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*- LOCAL BEST-EFFORT DATA VCs FOR LISs 



LOCAL QoS DATA VCs FOR LISs 
MSW-TO-MSW QoS DATA VC 

RSVP OVER ATM EXAMPLE: STAGE 3 

FIG. 8 
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